page_title: SMART Process Acceleration Development Environment
section_title: Creating clear requirements
hierarchical_section_title: SMART Process Acceleration Development Environment / Details / Creating clear requirements
caption_attribution_description: English: Example of a visual specification of a end result using SMART Requirements 2.0
context_page_description: SPADE is a software development productivity and quality tool used to create professional software in a short time and with little effort. As seen in the diagram SPADE automates many manual activities of the Software development process. It therefore takes less time and effort to perform the full software development cycle.
  With SPADE the remaining manual steps are:
  Reqs: gathering the wishes of the customer and documenting them in clear requirements, user stories or similar.
  Test cases: creating integration tests cases that will be run automatically during Test.
  Test: usability testing and testing integration with external systems.
  Accept: accepting the created solution
  Automation of the other steps is possible because the requirements are specified clearly by using the method SMART Requirements 2.0. SPADE then uses intelligent algorithms that incorporate dependency analysis and a set of design patterns to transform these requirements to an optimized business process design, including the flow of user interactive and fully automated steps that are part of this business process.
context_section_description: The input of SPADE are end result oriented business requirement specifications. These explain:
  This information is placed in a document, usually a file of some sort and is written down using a formal specification language. Below is an example in gray with explanation in italic text.
  Start by naming the process and its most important piece of information as its subject
  Process 'Order products' with subject #('Order': ORDER)
  
  Sum up the high level results. Double quotes are used to define requirements and help to create a result oriented break down structure. 
   The following applies:
       "Customer has ordered products"
       and
       "Customer has an invoice if approved"
       and
       "The order needs to be approved if needed"
  Define the requirements clearly. Use if-then-else to define 'When' results should apply or should be produced. 'Where' the information is coming from is defined using references. For instance ORDER.approved is a piece of available information that is either produced during the process or is already an available piece of information. Some requirements (results) can be specified visually. To your right the "Customer has an invoice" is specified as an e-mail. 
   "Customer has an invoice if approved" =
       if ORDER.approved then "Customer has an invoice"
  
   "The order needs to be approved if needed" =
       if   "too expensive"
       then "The order needs to be approved"
       else ORDER.approved = true
  
   "too expensive" =
       ORDER.total > 500
  A person can also be a source of information by stating 'input from' followed by a name that identifies the role of this person or the actual user. In the example below a person with the role CONTROLLER. If this persons in turn need information to be able to give this input, you need to state that this input can be given 'based on' certain other information. In this case the date, the BUYER and the LINES of the ORDER. 
   "The order needs to be approved" =
       ORDER.approved = input from CONTROLLER based on #(ORDER.date, ORDER.BUYER, ORDER.LINES)
  
  The actual person that is giving the input at the time the system is used (the current user), can also be used as a piece of information. The example below defines the ORDER and its attributes. One if the attributes is called BUYER and this is filled with the actual CUSTOMER that (at the time the actual process runs) is playing that role, in other words giving the input. 
   "Customer has ordered products" =
       One ORDER exists in ORDERS with:
           date        = currentDate()
           BUYER       = CUSTOMER
           LINES       = "order lines"
  
   "order lines" =
       Several LINE exist in ORDER_LINES with:
           PRODUCT = input from CUSTOMER
           number  = input from CUSTOMER
  The requirements also require a business or logical data model. Most of the logical data model can be derived from the requirements. For instance it knows which entities are needed (ORDERS, ORDER_LINES and PRODUCST) and in some cases it also can derive the type of an attribute. For instance __approved__ can only be true or false because it is used as a condition and LINES should be a relation to ORDER_LINES. Some types however cannot be derived and need to be defined explicitly in this data model. Below is an example of this data model.
     ORDERS =
         date                 : date
         BUYER                : USERS(1)
         LINES                : ORDER_LINES(*) opposite of ORDER
         approved             : boolean
         total                : decimal(10,2) = sum(LINES.total)
         summary              : text displayed = '{total} euro by {BUYER.firstName} {BUYER.lastName} on {date}'
     ORDER_LINES =
         PRODUCT     : PRODUCTS(1)
         number      : integer
         ORDER       : ORDERS(1) opposite of LINES
         total       : decimal(10,2) = number * PRODUCT.price
     PRODUCTS =
         name         : text
         price        : decimal(10,2)
         summary      : text displayed = '{name} ({price} euro)'
  Most of this data model is pretty straight forward and resemble other data modelling techniques. Some things stand out:
  Relational at
caption: Visual specification of requirement "Customer has an invoice"
exif: {}