Close

Requirements Framework

A project log for Open Source Analog Effects Pedal

A modular platform for developing and trading guitar (and other) audio effects. Focus on, but not limited to, pure analog signal path.

joshJosh 08/09/2014 at 02:450 Comments

Why Requirements? 

In the aircraft industry where I come from, the exact  form of an item is the last thing that takes shape. Requirements based design allows the object to take a new and sometimes completely unexpected paths. The following requirements framework will form a basis for mapping out the specific requirements after the data is returned from the surveys. The following framework comes from section 5 in SAE ARP4754, and although the process in the spec is ridiculous for a design such as this, following the general idea will give a solid design path. I have abbreviated the section after the break for those interested.

Requirements Framework

Each major category is listed along with a quick description. The ARP sections group the below headings 2.0 through 7.0 under a single heading of "Functional," however this extra level is not necessary in this case, and the functional sections flattened to the top level.

1.0 Safety Requirements (anything that has an unsafe consequence)

2.0 User (desires of the people actually using the device)

3.0 Operational (interface/communication between user and system)

4.0 Performance (accuracy, fidelity, range, resolution, speed, and response times)

5.0 Physical and Installation (size, mounting, power, cooling, adjustment, and handling)

6.0 Maintainability (address probable failures)

7.0 Interface (interface/communication between this system and other systems)

8.0 Derived Requirements (Result from design iteration)

Requirements Process

The above framework categorizes the requirements, but the process to develop requirements is iterative. After the surveys are processed, key features of the popular pedals will be listed in the framework above. Other information from speaking with artists will also be listed in the framework. This forms the high-level requirements for the project. 

These high level requirements may not be capable of direct implementation in the design, and so they must be broken down into a second level of requirements that can directly relate to design attributes. An example of a high-level requirement would be "input from a guitar" whereas the realizable breakdown would be "minimum input 10mV ac peak-to-peak" and  1/4" tip-sleeve female jack in section 2.6, and in 2.3 a requirement to process an input signal ranging from 20-20,000 Hz.

After the surveys are in, the results will be used to start this process. 

ARP4754A excerpt:

5.3.1 Types of Requirements

The requirements associated with a given function define the way the function acts in its environment and include the definition of the user/machine interface. [...] 

5.3.1.1  Safety Requirements 

[...] Requirements that are defined to prevent failure conditions or to provide safety related functions should be uniquely identified and traceable through the levels of development.  [...]

5.3.1.2 Functional Requirements 

Functional requirements are those necessary to obtain the desired performance of the system under the conditions specified.  They are a combination of customer desires, operational constraints, regulatory restrictions, and implementation realities.  [...] 

5.3.1.2.1  Customer Requirements 

[...] Requirements may include those associated with the operator's intended payload, route system, operating practices, maintenance concepts, and desired features. 

5.3.1.2.2  Operational Requirements 

Operational requirements define the interfaces between the flight crew and each functional system, the maintenance crew and each aircraft system, and various other aircraft support people and related functions or equipment.  Actions, decisions, information requirements and timing constitute the bulk of the operational requirements.  [...]

5.3.1.2.3  Performance Requirements 

Performance requirements define those attributes of the function or system that make it useful to the aircraft and its operation.  In addition to defining the type of performance expected, performance requirements include function specifics such as: accuracy, fidelity, range, resolution, speed, and response times. 

5.3.1.2.4  Physical and Installation Requirements 

Physical and installation requirements relate the physical attributes of the system to the aircraft environment.  They may include: size, mounting provisions, power, cooling, environmental restrictions, visibility, access, adjustment, handling, and storage.  Production constraints may also play a role in establishing these requirements. 

5.3.1.2.5 Maintainability Requirements

Maintainability requirements include scheduled and unscheduled maintenance requirements and any links to safety related functions. Factors such as the percent of failure detection or the percent of fault isolation may also be important. Provisions for external test equipment signals and connections should be defined in these requirements. 

5.3.1.2.6 Interface Requirements

Interface requirements include the physical system and item interconnections along with the relevant characteristics of the specific information communicated. The interfaces should be defined with all inputs having a source and all output destinations defined. The interface descriptions should fully describe the behavior of the signals. 

5.3.1.3 Additional Certification requirements

[Outside of the scope of this project]

5.3.1.4 Derived Requirements

At each phase of the development activity, decisions are made as to how particular requirements or groups of requirements are to be met. The consequences of these design choices become requirements for the next phase of the development. Since these requirements result from the design process itself, they may not be uniquely related to a higher level requirement and are referred to as derived requirements.

8/11 Edit - Flattened subgroups of functional requirements into top level categories.

Discussions