For demonstration purposes, the following lines portray sets of requirements diverging from standard  good practices: 

​

 System A: Thermostat application
     - the interface should be nice -> Ambiguous 
     - the interface must ensure enough space for operation  -> Ambiguous 
     - the menu must be easy to be used and small -> Ambiguous 
     - the user should be able to set temperature -> Ambiguous , incomplete, unverifiable
     - the user can set the time -> Ambiguous , incomplete, unverifiable, not necessary unless the thermostat is expected to perform a clock function as well. The requirement is unfounded. Assuming a temperature schedule is desired, the requirement must include temperature as a  parameter.
    - in setting the temperature, a floating variable with range -12,555 to +12,555 should be used on buffer memory and the control strategy should check the value against a permitted temperature range; upon success, the value is accepted by the temperature regulator  ->  NOT implementation independent and NOT singular/atomic

​

System B: ECU for motor control
     - The Module's software shall ensure second order closed loop control, piloting inlet valves in order to ensure stoichiometric charge mixture inside the combustion chamber. -> Ambiguous, incomplete, unverifiable, not traced to parent (on system level), missing applicability, not singular/atomic
 

       

​

 

 

 

Our guide on writing Requirements 

​

​

​

    ECU Design conforms to standard ISO29148 "Systems and software engineering — Life cycle processes — Requirements engineering"

​

   Characteristics on writing requirements:

• Necessary
• Implementation independent

• Unambiguous
• Complete
• Singular
• Achievable
• Verifiable
• Conforming

​

   Attributes on writing requirements:

• Trace to parent
• Trace to source
• Trace to interface definition
• Trace to peer requirements
• Trace to verification method
• Trace to verification requirement(s)
• Trace to verification results
• Requirements verification status
• Requirements validation status
• Priority

• Criticality
• Risk
• Key driving requirement (KDR)
• Owner
•Rationale
• Applicability
• Type

​

​

​

                                        Requirements Interchange Format ReqIF

  

 

 

    ReqIF ( Requirements Interchange Format) is widely adopted file exchange format employed in sharing of requirements, attributes, additional files such as supporting images, supporting UML / SysML  diagrams. ReqIF ensures source tracing and interface definition of requirements. 
    In common use and operating on ReqIF format are software tools like IBM Doors or Siemens Polarion. The strength of such tools resides in wide adoption on the market, as they substitute cloud storage and distribution of .csv files and afford an easy table-like display of requirements (while avoiding attributes of the requirements). 

​

 IBM Doors and other likewise tools, though costly, provide built-in capability for linking and traceability between objects ranging from concept UML/ SysML diagrams to Requirements Definition diagrams and further to implementation diagrams (including schematic capture, PCB, software documents). 

​

  ECU Design can perform study cases and present customers with optimum solutions for repositories based on IBM-Doors tool (ReqIF format) or SparxSystems-RaQuest (.csv format). Both tools operate in conjunction with Enterprise Architect for requirements diagrams.