Requirements Engineering. Objectives. System requirements. Types of requirements. FAQS about requirements. Requirements problems

Transcription

1 Reqirements Engineering Objectives An introdction to reqirements Gerald Kotonya and Ian Sommerville To introdce the notion of system reqirements and the reqirements process. To explain how reqirements fits into a broader system process To explain the importance of the reqirements docment G. Kotonya and I. Sommerville 1998 Slide 1 G. Kotonya and I. Sommerville 1998 Slide 2 reqirements Types of reqirements Define what the system is reqired to do and the constraints nder which it is reqired to operate The system shall maintain records of all library materials inclding books, serials, newspapers and magazines, video and adio tapes, reports, collections of transparencies, compter disks and CD-ROMs. The system shall allow sers to search for an item by title, athor, or by ISBN. The system s ser interface shall be implemented sing a World-Wide-Web browser. The system shall spport at least 20 transactions per second. The system facilities which are available to pblic sers shall be demonstrable in 10 mintes or less. Very general reqirements which set ot in broad terms what the system shold do. Fnctional reqirements which define part of the system s fnctionality. Implementation reqirements which state how the system mst be implemented. Performance reqirements which specify a minimm acceptable performance for the system. Usability reqirements which specify the maximm acceptable time to demonstrate the se of the system. G. Kotonya and I. Sommerville 1998 Slide 3 G. Kotonya and I. Sommerville 1998 Slide 4 Reqirements problems FAQS abot reqirements The reqirements don t reflect the real needs of the cstomer for the system. Reqirements are inconsistent and/or incomplete. It is expensive to make changes to reqirements after they have been agreed. There are misnderstandings between cstomers, those developing the system reqirements and software engineers developing or maintaining the system. What are reqirements? A statement of a system service or constraint What is reqirements? The processes involved in developing system reqirements How mch does reqirements cost? Abot 15% of system development costs What is a reqirements process? The strctred set of activities involved in developing system reqirements G. Kotonya and I. Sommerville 1998 Slide 5 G. Kotonya and I. Sommerville 1998 Slide 6

2 FAQs contd. FAQs contd. What happens when the reqirements are wrong? s are late, nreliable and don t meet cstomers needs What is the relationship between reqirements and design? Is there an ideal reqirements process? No - processes mst be tailored to organisational needs What is a reqirements docment? Reqirements and design are interleaved. They shold, ideally, be separate processes bt in practice this is impossible What is reqirements management? The processes involved in managing changes to reqirements The formal statement of the system reqirements What are system stakeholders? Anyone affected in some way by the system G. Kotonya and I. Sommerville 1998 Slide 7 G. Kotonya and I. Sommerville 1998 Slide 8 s Classes of cstom systems There is a close relationship between software and more general system reqirements Compter-based systems fall into two broad categories: User-configred systems where a prchaser pts together a system from existing software prodcts Cstom systems where a cstomer prodces a set of reqirements for hardware/software system and a contractor develops and delivers that system Information systems Primarily concerned with processing information which is held in some database. Embedded systems s where software is sed as a controller in some broader hardware system Command and control systems Essentially, a combination of information systems and embedded systems where special prpose compters provide information which is collected and stored and sed to make decisions G. Kotonya and I. Sommerville 1998 Slide 9 G. Kotonya and I. Sommerville 1998 Slide 10 Emergent properties The systems process Emergent properties are properties of the system as a whole and only emerge once al of its individal sb-systems have been integrated Examples of emergent properties Reliability Maintainability Performance Usability Secrity Safety reqirements Architectral design Reqirements partitioning Software reqirements Sb-system development integration validation G. Kotonya and I. Sommerville 1998 Slide 11 G. Kotonya and I. Sommerville 1998 Slide 12

3 activities activities reqirements Sb-system development The reqirements for the system as a whole are established and written to be nderstandable to all stakeholders The hardware and software sb-systems are designed and implemented in parallel. Architectral design integration The system is decomposed into sb-systems Reqirements partitioning Reqirements are allocated to these sb-systems Software reqirements The hardware and software sb-systems are pt together to make p the system. validation The system is validated against its reqirements. More detailed system reqirements are derived for the system software G. Kotonya and I. Sommerville 1998 Slide 13 G. Kotonya and I. Sommerville 1998 Slide 14 Reqirements docment Reqirements docment The reqirements docment is a formal docment sed to commnicate the reqirements to cstomers, engineers and managers. The reqirements docment describes: The services and fnctions which the system shold provide The constraints nder which the system mst operate Overall properties of the system i.e.. constraints on the system s emergent properties Definitions of other systems which the system mst integrate with. The reqirements docment describes: Information abot the application domain of the system e.g. how to carry ot particlar types of comptation Constraints on the processes sed to develop the system Description of the hardware on which the system is to rn In addition, the reqirements docment shold always inclde an introdctory chapter which provides an overview of the system, bsiness needs spported by the system and a glossary which explains the terminology sed. G. Kotonya and I. Sommerville 1998 Slide 15 G. Kotonya and I. Sommerville 1998 Slide 16 Users of reqirements docments Reqirements docment strctre cstomers specify the reqirements and read them to check they meet their needs IEEE/ANSI standard proposes a strctre for software reqirements docments Project managers Use the reqirements docment to plan a bid for system and to plan the system development process engineers Use the reqirements to nderstand the system being developed Introdction 1.1 Prpose of reqirements docment 1.2 Scope of the prodct 1.3 Definitions, acronyms and abbreviations 1.4 References test engineers 1.5 Overview of the remainder of the docment Use the reqirements to develop validation tests for the system maintenance engineers Use the reqirements to help nderstand the system G. Kotonya and I. Sommerville 1998 Slide 17 G. Kotonya and I. Sommerville 1998 Slide 18

4 Reqirements docment strctre Adapting the standard 2. General description 2.1 Prodct perspective 2.2 Prodct fnctions 2.3 User characteristics 2.4 General constraints 2.5 Assmptions and dependencies 3. Specific reqirements Covering fnctional, non-fnctional and interface reqirements. The IEEE standard is a generic standard which is intended apply to a wide range of reqirements docments. In general, not all parts of the standard are reqired for all reqirements docments Each organisation shold adapt the standard depending on the type of systems it develops 4. Appendices Index Consider a company (XYZ) that develops scientific instrments G. Kotonya and I. Sommerville 1998 Slide 19 G. Kotonya and I. Sommerville 1998 Slide 20 Preface This shold define the expected readership of the docment and describe its version history inclding a rationale for the creation of a new version and a smmary of the changes made in each version. Introdction This shold define the prodct in which the software is embedded, its expected sage and present and overview of the fnctionality of the control software. Glossary This shold define all technical terms and abbreviations sed in the docment. General ser reqirements This shold define the system reqirements from the perspective of the ser of the system. These shold be presented sing a mixtre of natral langage and diagrams. architectre This chapter shold present a high-level overview of the anticipated system architectre showing the distribtion of fnctions across system modles. Architectral components which are to be resed shold be highlighted. Hardware specification This is an optional chapter specifying the hardware that the software is expected to control. It may be omitted if the standard instrment platform is sed. G. Kotonya and I. Sommerville 1998 Slide 21 G. Kotonya and I. Sommerville 1998 Slide 22 Detailed software specification This is a detailed description of the fnctionality expected of the software of the system. It may inclde details of specific algorithms which shold be sed for comptation. If a prototyping approach is to be sed for development on the standard instrment platform, this chapter may be omitted. Reliability and performance reqirements This chapter shold describe the reliability and performance reqirements which are expected of the system. These shold be related to the statement of ser reqirements in Chapter 4. The following appendices may be inclded where appropriate: Hardware interface specification Software components which mst be resed in the system implementation Data strctre specification Data-flow models of the software system Detailed object models of the software system Index G. Kotonya and I. Sommerville 1998 Slide 23 G. Kotonya and I. Sommerville 1998 Slide 24

5 Writing reqirements Writing essentials Reqirements are sally written as paragraphs of natral langage text spplemented by diagrams and eqations Reqirements are read more often than they are written. Yo shold invest time to write readable and nderstandable reqirements Problems with reqirements se of complex conditional clases which are confsing sloppy and inconsistent terminology writers assme readers have domain knowledge Do not assme that all readers of the reqirements have the same backgrond and se the same terminology as yo Allow time for review, revision and re-drafting of the reqirements docment G. Kotonya and I. Sommerville 1998 Slide 25 G. Kotonya and I. Sommerville 1998 Slide 26 Writing gidelines Key points Define standard templates for describing reqirements Use langage simply consistently and concisely Use diagrams appropriately Spplement natral langage with other description of reqirements Specify reqirements qantitatively Reqirements define what the system shold provide and define system constraints Reqirements problems lead to late delivery and change reqests after the system is in se Reqirements is concerned with eliciting, analysing, and docmenting the system reqirements G. Kotonya and I. Sommerville 1998 Slide 27 G. Kotonya and I. Sommerville 1998 Slide 28 Key points s is concerned with systems as a whole inclding hardware, software and operational processes The reqirements docment is the definitive specification of reqirements for cstomers, engineers and managers. The reqirements docment shold inclde a system overview, glossary, statement of the fnctional reqirements and the operational constraints G. Kotonya and I. Sommerville 1998 Slide 29