▁all ▁input ▁through ▁the ▁architect . ▁ ▁Direct ▁interaction ▁with ▁project ▁engine ers ▁is ▁generally ▁disc ou rag ed ▁as ▁the ▁chance ▁of ▁mut ual ▁misunder standing ▁is ▁very ▁high . ▁ ▁The ▁user ▁requirements ' ▁specification ▁should ▁be ▁a ▁joint ▁product ▁of ▁the ▁user ▁and ▁hardware ▁architect ▁( or , ▁the ▁systems ▁and ▁hardware ▁architect s ): ▁the ▁user ▁brings ▁his ▁ ▁needs ▁and ▁wish ▁list , ▁the ▁architect ▁brings ▁knowledge ▁of ▁what ▁is ▁likely ▁to ▁prove ▁do able ▁within ▁cost ▁and ▁time ▁constraints . ▁ ▁When ▁the ▁user ▁needs ▁are ▁translated ▁into ▁a ▁set ▁of ▁high ▁level ▁requirements ▁is ▁also ▁the ▁best ▁time ▁to ▁write ▁the ▁first ▁version ▁of ▁the ▁accept ance ▁test , ▁which ▁should , ▁there after , ▁be ▁religious ly ▁kept ▁up ▁to ▁date ▁with ▁the ▁requirements . ▁ ▁That ▁way , ▁the ▁user ▁will ▁be ▁absolutely ▁clear ▁about ▁what ▁s / he ▁is ▁getting . ▁ ▁It ▁is ▁also ▁a ▁saf egu ard ▁against ▁un test able ▁requirements , ▁misunder stand ings , ▁and ▁requirements ▁cre ep . ▁ ▁The ▁development ▁of ▁the ▁first ▁level ▁of ▁hardware ▁engineering ▁requirements ▁is ▁not ▁a ▁purely ▁analyt ical ▁exercise ▁and ▁should ▁also ▁involve ▁both ▁the ▁hardware ▁architect ▁and ▁engineer . ▁ ▁If ▁any ▁comprom ises ▁are ▁to ▁be ▁made — to ▁meet ▁constraints ▁like ▁cost , ▁schedule , ▁power , ▁or ▁space , ▁the ▁architect ▁must ▁ensure ▁that ▁the ▁final ▁product ▁and ▁overall ▁look ▁and ▁feel ▁do ▁not ▁st ray ▁very ▁far ▁from ▁the ▁user ' s ▁intent . ▁