RequirementsEngineering K S 1998

Requirements Engineering Objectives
u To introduce the notion of system requirements

and the requirements engineering process.
An introduction to requirements
u To explain how requirements engineering fits into
engineering a broader system engineering process
Gerald Kotonya and Ian Sommerville u To explain the importance of the requirements
document
©G. Kotonya and I. Sommerville 1998 Slide 1 ©G. Kotonya and I. Sommerville 1998 Slide 2
System requirements Types of requirements

u Define what the system is required to do and the u Very general requirements which set out in broad terms what
constraints under which it is required to operate the system should do.
• The system shall maintain records of all library materials u Functional requirements which define part of the system’s
including books, serials, newspapers and magazines, video and functionality.
audio tapes, reports, collections of transparencies, computer
disks and CD -ROMs. u Implementation requirements which state how the system
• The system shall allow users to search for an item by title, must be implemented.
author, or by ISBN. u Performance requirements which specify a minimum
• The system’s user interface shall be implemented using a acceptable performance for the system.
World-Wide-Web browser.
u Usability requirements which specify the maximum
• The system shall support at least 20 transactions per second.
acceptable time to demonstrate the use of the system.
• The system facilities which are available to public users shall be
demonstrable in 10 minutes or less.
Requirements problems FAQS about requirements

u The requirements don’t reflect the real needs of u What are requirements?
the customer for the system. • A statement of a system service or constraint
u Requirements are inconsistent and/or incomplete. u What is requirements engineering?
u It is expensive to make changes to requirements • The processes involved in developing system requirements
after they have been agreed. u How much does requirements engineering cost?
u There are misunderstandings between customers, • About 15% of system development costs
those developing the system requirements and u What is a requirements engineering process?
software engineers developing or maintaining the • The structured set of activities involved in developing system
requirements
system.
FAQs contd. FAQs contd.
u What happens when the requirements are wrong? u What is the relationship between requirements
• Systems are late, unreliable and don’t meet customers needs and design?
u Is there an ideal requirements engineering • Requirements and design are interleaved. They should, ideally,
be separate processes but in practice this is impossible
process?
• No - processes must be tailored to organisational needs u What is requirements management?
• The processes involved in managing changes to requirements
u What is a requirements document?
• The formal statement of the system requirements
u What are system stakeholders?
• Anyone affected in some way by the system
Systems engineering Classes of custom systems

u There is a close relationship between software u Information systems
and more general system requirements • Primarily concerned with processing information which is held
in some database.
u Computer-based systems fall into two broad
u Embedded systems
categories:
• Systems where software is used as a controller in some broader
• User-configured systems where a purchaser puts together a hardware system
system from existing software products
• Custom systems where a customer produces a set of u Command and control systems
requirements for hardware/software system and a contractor • Essentially, a combination of information systems and
develops and delivers that system embedded systems where special purpose computers provide
information which is collected and stored and used to make
decisions
Emergent properties The systems engineering process

u Emergent properties are properties of the system System System
as a whole and only emerge once al of its requir ements validation
engineering
individual sub-systems have been integrated
Architectural System
u Examples of emergent properties d esign integration
• Reliability
Requirements Sub-system
• Maintainability partitioning development
• Performance
• Usability So ftware
requiremen ts
• Security engineering
• Safety
System engineering activities System engineering activities
u System requirements engineering u Sub-system development
• The requirements for the system as a whole are established and • The hardware and software sub-systems are designed and
written to be understandable to all stakeholders implemented in parallel.
u Architectural design u System integration
• The system is decomposed into sub-systems • The hardware and software sub-systems are put together to
make up the system.
u Requirements partitioning
• Requirements are allocated to these sub-systems u System validation
• The system is validated against its requirements.
u Software requirements engineering
• More detailed system requirements are derived for the system
software
Requirements document Requirements document

u The requirements document is a formal document u The requirements document describes:
used to communicate the requirements to • Information about the application domain of the system e.g. how to
carry out particular types of computation
customers, engineers and managers.
• Constraints on the processes used to develop the system
u The requirements document describes: • Description of the hardware on which the system is to run
• The services and functions which the system should provide
u In addition, the requirements document should
• The constraints under which the system must operate
• Overall properties of the system i.e.. constraints on the system ’s
always include an introductory chapter which
emergent properties provides an overview of the system, business needs
• Definitions of other systems which the system must integrate supported by the system and a glossary which
with. explains the terminology used.
Users of requirements documents Requirements document structure

u System customers u IEEE/ANSI 830-1993 standard proposes a
• specify the requirements and read them to check they meet their needs structure for software requirements documents
u Project managers u Introduction
• Use the requirements document to plan a bid for system and to plan 1.1 Purpose of requirements document
the system development process 1.2 Scope of the product
u System engineers 1.3 Definitions, acronyms and abbreviations
• Use the requirements to understand the system being developed 1.4 References
1.5 Overview of the remainder of the document
u System test engineers
• Use the requirements to develop validation tests for the system
u System maintenance engineers
• Use the requirements to help understand the system
Requirements document structure Adapting the standard
u 2. General description u The IEEE standard is a generic standard which is
2.1 Product perspective intended apply to a wide range of requirements
2.2 Product functions documents.
2.3 User characteristics
2.4 General constraints u In general, not all parts of the standard are
2.5 Assumptions and dependencies required for all requirements documents
u 3. Specific requirements u Each organisation should adapt the standard
Covering functional, non-functional and interface requirements. depending on the type of systems it develops
u 4. Appendices u Consider a company (XYZ) that develops
u Index scientific instruments
Organisation XYZ standard Organisation XYZ standard

u Preface u General user requirements
• This should define the expected readership of the document and • This should define the system requirements from the perspective of
describe its version history including a rationale for the creation the user of the system. These should be presented using a mixture
of a new version and a summary of the changes made in each of natural language and diagrams.
version. u System architecture
u Introduction • This chapter should present a high-level overview of the
• This should define the product in which the software is anticipated system architecture showing the distribution of
embedded, its expected usage and present and overview of the functions across system modules. Architectural components which
functionality of the control software. are to be reused should be highlighted.
u Glossary u Hardware specification

• This should define all technical terms and abbreviations used in • This is an optional chapter specifying the hardware that the
the document. software is expected to control. It may be omitted if the standard
instrument platform is used.
Organisation XYZ standard Organisation XYZ standard

u Detailed software specification u The following appendices may be included where
• This is a detailed description of the functionality expected of the appropriate:
software of the system. It may include details of specific • Hardware interface specification
algorithms which should be used for computation. If a
• Software components which must be reused in the system
prototyping approach is to be used for development on the
implementation
standard instrument platform, this chapter may be omitted.
• Data structure specification
u Reliability and performance requirements • Data -flow models of the software system
• This chapter should describe the reliability and performance • Detailed object models of the software system
requirements which are expected of the system. These should be
related to the statement of user requirements in Chapter 4. u Index
Writing requirements Writing essentials
u Requirements are usually written as paragraphs of u Requirements are read more often than they are
natural language text supplemented by diagrams written. You should invest time to write readable
and equations and understandable requirements
u Problems with requirements u Do not assume that all readers of the
• use of complex conditional clauses which are confusing requirements have the same background and use
• sloppy and inconsistent terminology the same terminology as you
• writers assume readers have domain knowledge
u Allow time for review, revision and re-drafting of
the requirements document
Writing guidelines Key points

u Define standard templates for describing requirements u Requirements define what the system should
u Use language simply consistently and concisely provide and define system constraints
u Use diagrams appropriately u Requirements problems lead to late delivery and
u Supplement natural language with other description of change requests after the system is in use
requirements u Requirements engineering is concerned with
u Specify requirements quantitatively eliciting, analysing, and documenting the system
requirements
Key points
u Systems engineering is concerned with systems
as a whole including hardware, software and
operational processes
u The requirements document is the definitive
specification of requirements for customers,
engineers and managers.
u The requirements document should include a
system overview, glossary, statement of the
functional requirements and the operational
constraints
©G. Kotonya and I. Sommerville 1998 Slide 29

RequirementsEngineering K S 1998

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

RequirementsEngineering K S 1998

Hochgeladen von

Copyright:

Verfügbare Formate

Requirements Engineering Objectives

u To introduce the notion of system requirements

System requirements Types of requirements

Requirements problems FAQS about requirements

Systems engineering Classes of custom systems

Emergent properties The systems engineering process

Requirements document Requirements document

Users of requirements documents Requirements document structure

Organisation XYZ standard Organisation XYZ standard

u Glossary u Hardware specification

Organisation XYZ standard Organisation XYZ standard

Writing guidelines Key points

Das könnte Ihnen auch gefallen