Page 24 - Software and Systems Requirements Engineering in Practice
P. 24

P r e f a c e   xxiii


                      be carefully documented, traced, reviewed, and tested. We have also
                      had to develop expertise on subjects that are not commonly taught at
                      universities, such as hazard analysis.
                         Requirements  engineering  has  become  more  complicated  over
                      time  as  the  complexity  of  the  products  we  desire  to  develop  has
                      increased. Thus, the requirements engineer is continually challenged
                      by issues of scale, unstable requirements, product complexity, and
                      managing change. Our experience has resulted from the opportunities
                      to work on, for example, a project that is defining the requirements
                      for an automobile infotainment system and then a few months later a
                      project  that  is  defining  the  requirements  for  a  medical  imaging
                      system.

                 How to Use This Book
                      Our  experience  is  with  requirements  engineering  for  products,
                      systems, and services; typically (but not always) with high software
                      content.  This  book  contains  RE  methods,  processes,  and  rules  of
                      thumb that have been derived from observed best practices of RE
                      across many such projects. Thus, this book is meant for software and
                      systems engineering professionals who are interested in learning new
                      or  validating  their  current  techniques  for  RE.  Such  professionals
                      include practicing requirements engineers, who should benefit most
                      from the best practices discussed. But, the book material may also be
                      useful to other engineering professionals, such as system architects,
                      testers,  developers,  and  engineering  managers.  The  book  may  be
                      useful to “not quite yet” practitioners such as graduate students in
                      software engineering, systems engineering, or computer science. We
                      would also hope that product or marketing managers would receive
                      valuable information from this book as they struggle with bringing
                      new products to a competitive market.
                         In  order  to  focus  on  best  practices  and  techniques  for  the
                      practitioner, there is very little introductory material presented, but
                      pointers  are  given  to  reference  books  that  cover  basic  software
                      engineering concepts. Thus, users of this book typically would have
                      at  least  an  undergraduate  degree  in  computer  science,  systems  or
                      software engineering and some experience developing systems.
   19   20   21   22   23   24   25   26   27   28   29