Support  /   WebEx  /   eTraining  /     /   Contact Us
Technology

Value proposition of Functional Requirements Analysis
and Risk Mitigation

Root cause analysis demonstrates the sources of software, process or product development problems often go back to the earliest phase of the development process, requirements engineering. Yet, most project teams still move into the design phase with requirement lists but no real approach to the quality of these lists. This ad-hoc approach results in design - document - review - fix iterative development cycles that can quickly exhaust available time and budgets.

A key component of improving team performance is to systematically address the quality of the requirements. Functional requirements analysis and risk reduction, using the Acclaro DFSS toolset, will:

  • Capture, analyze, verify and error proof requirements in a structure of stakeholder needs, functional (performance) requirements and constraints
  • Evaluate the robustness of the requirements and concept solution applying MIT's Axiomatic Design functional decomposition and coupling analysis
  • Provide a systematic and pre-emptive framework to assess and mitigate product and project risk

Question:

Why does this approach of functional requirements analysis shorten the development effort by so much?

Answer:

Functional requirements analysis and risk mitigation maximizes the completeness and quality of the requirements before the bulk of development work, minimizing the typical costly iterations of catching problems later in the development process.


 

Software and business process development problems avoided

Software iterations are costly, usually requiring magnitudes more time than doing the job right in the first place. If (new) programming staff has to first learn the code to implement a change, then a software function that would have taken a couple minutes to implement in the original development might take days in iteration (staff studies code, makes change, unit tests, problem fixes, QA regression testing.) This is hundreds (100x) times more effort. The secret to on-time on-budget software development programs is avoiding iterations.

These are the significant functions of the functional requirements analysis process that reduce iteration risk that do NOT occur in traditional software design processes:

1. Functional requirements analysis separates the business process design solution from the coding solution.

Software implements business processes. Most software design projects do not separate the process design from the programming. Input requirements are usually use cases, sequence diagrams and feature lists of the business process. Programmers then implement both the business process design and the coding design simultaneously. This is very costly for two important reasons. 1) Solving the business process and the coding implementation may be trivial if done separately, but doing both at the same time creates complexity. 2) Software programmers are often not the right people to be making business process design decisions. Much of software iteration is due to business process issues, not the software implementation.

2. Functional Requirements Analysis structure shows missing requirements.

How does a person find out if a puzzle is missing pieces? By assembling the puzzle, the missing pieces become obvious. An Axiomatic Design decomposition of functional requirements has a dependency structure, like a puzzle. All requirements must fit into the dependency structure, showing the missing functions like holes in a puzzle. Addressing the missing requirements BEFORE the coding, avoids traditional iterations.

3. A functional requirements analysis for the business process solution can be assessed for product and project risks before the coding effort.

Fault Tree Analysis (FTA) and Failure Mode and Effects Analysis (FMEA) and project risk assessment can be systematically performed on the functional requirements analysis of the business process design. This is an efficient process to identify and avoid problems. Traditional software design usually ignores failure and fault analysis and simply fixes problems when found during test or deployment. And even if rarely done, it is done after coding which still creates software iterations.

4. A completed Functional Requirements Analysis can be used to prototype a test process to capture problems before the coding effort.

Functional requirements analysis provides a complete set of use cases and data fields which define the business process and which then can be modeled and tested before the coding effort. This finds problems before the problems are coded into the solution. Traditional software design processes do not test the business process design and will require iterations to fix problems later in the development process.

5. Top down functional decomposition yields lean designs

Most software business process designs are bottom up design processes that generate requirements full of excess features. In fact, many programmers commonly add features for additional functionality under the false assumption this adds value. Functional requirements analysis demands that any wasteful features that do not support a higher function must be removed.

6. The functional requirements analysis demands a Design for Six Sigma quality function where top level functional requirements are verified to stakeholder needs.

Top level functions on the functional requirements analysis process are formally traced to a stakeholder's analysis and document the business requirements for the system under design. Traditionally, there is no validation of the business function of the software system under design which causes unclear relationships and misalignments between business goals and software design in many development projects.

What are some of the major root causes of project failure?

Internet search will consistently identify the following issues:

  • Lack of User Involvement
  • Poor or undocumented requirements
  • Long or Unrealistic Time Scales
  • Scope Creep or lack of requirement change control systems
  • Inadequately trained and/or inexperienced project managers
  • Failure to set and manage expectations
  • Failure to adequately identify, document and track requirements
  • Poor plans and planning processes
  • Poor effort estimation
  • Misalignment between the project team and the business
  • Inadequate communication, including progress tracking and reporting

Functional Requirements Analysis directly addresses many of these issues.

 

Product development problems avoided

These are the significant functions of the Functional Requirements Analysis and Risk Mitigation process that reduce iteration risk that do NOT occur in traditional product development processes.

1. Functional requirements analysis improves innovation by differentiating the design process from the solution space.

Generally, designers jump to a solution, and then view the balance of the design from the limiting framework of their initial solution space. Many creative solutions are lost. By completing a requirements analysis in the function space, innovation is not stifled.

2. Functional Requirements Analysis structure captures missing requirements BEFORE design generation, avoiding traditional costly design iterations.

How does a person find out if a puzzle is missing pieces? By assembling the puzzle, the missing pieces become obvious. Like a puzzle, an Axiomatic Design decomposition of functional requirements has dependency structure where all the requirements must fit. Missing requirements show up like holes in a puzzle.

3. The functional requirements decomposition can be risk assessed and risk mitigated BEFORE the bulk of design work, avoiding traditional costly design iterations.

Fault Tree Analysis (FTA), Failure Mode and Effects Analysis (FMEA) and project risk assessment (probability-severity diagrams) can be systematically done during functional requirements analysis. This is an efficient process to identify and avoid problems BEFORE the design is generated. Traditional design processes assess failure modes and fault analysis AFTER the design has been generated, creating considerable iteration and rework.

4. The Axiomatic Design approach drives designers to a first pass best design using logical and rational thought processes.

Gone are the days of ad hoc brainstorming of designs in the solution space, where most concepts are then compared and quickly rejected. Proceed systematically on developing a functional performance requirements model of working solutions.

5. Top down functional decomposition yields lean designs

Most requirement lists are generated with bottom up processes generating excess features. Also, designers commonly add features for additional functionality under the false assumption this adds value. Functional requirements analysis demands that all requirements must support a higher function or be removed.

6. The functional requirements analysis provides a Design for Six Sigma (DFSS) quality function where top level functional requirements are verified to stakeholder needs.

Functions on the functional requirements analysis process are formally traced to a stakeholder's analysis and document the requirements for the system under design. Traditionally, there is no validation of the business function of the system under design which causes unclear relationships and misalignments between business goals and design in many development projects.

Some question and answers:

What are some of the major root causes of project failure?

Internet search will consistently identify the following issues

  • Lack of User Involvement
  • Poor or undocumented requirements
  • Long or Unrealistic Time Scales
  • Scope Creep or lack of requirement change control systems
  • Inadequately trained and/or inexperienced project managers
  • Failure to set and manage expectations
  • Failure to adequately identify, document and track requirements
  • Poor plans and planning processes
  • Poor effort estimation
  • Misalignment between the project team and the business
  • Inadequate communication, including progress tracking and reporting

Why aren't current CAD tools a solution to these problems?

CAD tools actually contribute to the problem of bad conceptual design. In today's CAE and CAD-centric environments, designers jump to committing their first pass approaches to CAD. This design and documentation development time is substantial as CAD systems demand a wealth of detail to represent designs. This results in delays before CAD documentation can be assessed in a collaborative development environment. Building CAD in the initial design process means that key aspects of product or system design quality such as performance, cost, completeness, risk, robustness or safety can't be structured and independently assessed until CAD documentation release. As such, even when quality or cost issues are now found, it is too late and the cost in time and budget of repeating a CAD design cycle is so high that design teams resort to 'patching' rather than properly re-iterating the design.

We implement a gate review process for design. What's wrong with this?

Gate review processes are good. But gate reviews are an inspection tool to be applied in reviewing work done (and generally already documented) in an 'inspect problems out' process. Acclaro DFSS is a pre-emptive process to avoid building problems into a design in the first place. Also, Axiomatic design prevents errors of omission and provides an analysis of functional robustness at that earliest point in the process where corrections can be made with no cost.

Acclaro® is a registered trademark of Functional Specs, Inc. Copyright© 1998-2017 Functional Specs, Inc. All Rights Reserved. Site Map