Requirements Engineering. Csaba Veres

Size: px

Start display at page:

Download "Requirements Engineering. Csaba Veres"

Robert Murphy
5 years ago
Views:

1 Requirements Engineering Csaba Veres

2 utline What is requirements engineering? Why is it important? How can you do it (properly)?

3 an Requirements engineering, P11 overview quality evaluation (validation) Using objects for Systems Analysis, P10, P13 differences in problem analysis, requirements, and design different objects in different phases Requirements engineering and COTS, P14 special methods Use cases, P12 motivation for use cases in requirements engineering how to write good use cases

4 oday s lecture Reading from Kotonya/Sommerville: Requirements Engineering: Processes and Techniques Processes Intro Requirements processes Techniques well known techniques

5 hy are requirements important? Many systems are delivered late and over budget. they often don t do what users wanted often not used to full effectiveness Proper requirements definition can ease the problems. Each stage of development can multiply he problem by 10 times discovering problems at requirements: cost 1 discovering after design: cost 10 discovering after implementation: cost 100 discovering after rollout to client: cost 1000

6 hat are requirements? Requirements define what the system is require to do, and the circumstances under which it mus operate. e.g. 1. The system shall maintain records of all library mater including books, serials, newspapers and magazines video and audio tapes, reports, collections of transparencies, computer disks and CD-ROMS. 2. The system shall allow the users to search for an item by title, author, or ISBN. 3. The system s user interface shall be implemented us WWW browser. 4. The system shall support at least 20 transactions per second. 5. The system facilities which are available to public use shall be demonstrable in 10 minutes or less.

7 hat sorts of requirements? The previous list contained different types of requirement: 1. Very general requirements that set out in broad terms what the system should do 2. Functional requirements 3. Implementation requirements 4. Performance requirements to specify minimum acceptable performance 5. Usability requirements

8 complex web of needs... Functional requirements Non functional requirements security speed usability (?) Organisational standards Other interacting systems

9 can lead to many problems Requirements don t reflect real needs Requirements are inconsistent/incomplete e.g. requirement 1) above... CDs don t have ISBN.. author? Misunderstandings between customers, users, developers... Requirements engineering aims at concrete epeatable methods for doing the job as we as possible

10 AQs about requirements hat are requirements? In addition to what we already talked about, requirements can relate to: user-level facility (e.g. word processor should have s checker ). general system property (e.g. the system should nev make personal information available ) i. specific constraint on the system (e.g. the sensor mu be polled 10 times a second ) v. business rules (specific computations, formulas). constraint on development (e.g. the system must be developed using Ada)

11 AQ Requirements can be about what the system has to do functional, non-functional how it has to do it domain experts

12 AQ hat is requirements engineering? Discovering, documenting, and maintaining equirements Systematic, repeatable techniques to make sure requirements are complete consistent relevant

13 AQ ow much does RE cost? Depends on the project Around 10% to 15% of total cost

14 AQ hat happens when the requirements are wrong? Late delivery and inflated cost End-users not satisfied with the system modification, abandoning Unreliable High cost of maintenance and modification

15 AQ hat is a requirements engineering process? Structured set of activities to derive, validate, and maintain requirements document elicitation analysis negotiation validation deally should include timelines, tools, esponsibilities, etc.

16 AQ there an ideal RE process? Yes. Only joking... System, organizational culture, etc. The few existing standards relate to proces outputs, not processes themselves

17 AQ hat is a requirements document? THE official statement of the system equirements Describes a number of lower level entities functional specifications, etc.)

18 AQ hat are stakeholders? Anyone who has a direct or indirect bearing on the system requirements end users, managers, development and maintenance engineers, customers who rely on the system, external bodies (e.g. tax departmen Make sure ALL stakeholders are consulted, or there will be trouble!

19 AQ w do requirements relate to design? Seperate activities? specification vs. solution what vs. how n reality, often there are overlaps system has to fit within existing environment (e.g. data h to be read from ORACLE DB ) large systems decompose into subsystems which have their own requirements re use of existing software re use of approved patterns or solutions

20 AQ hat is requirements management? The process of managing changes to equirements document Change control collect, verify, and assess changes Change impact management how does the change impact the whole system? economic feasability

21 ystems engineering Software requirements involves properties of the system as a whole software hardware operational processes Computer systems are either: user-configured no explicit system requirements COTS? custom made all stakeholders participate in requirements

22 ifferent types of system nformation systems process information typically database access standard hardware RE: primarily software requirements Embedded systems software used as a controller special purpose hardware and OS RE: hardware and software Command and control systems combined information and embedded special purpose systems to aide decision making e.g. air traffic control, railway traffic control, military RE: software, hardware, operational processes

23 mergent properties non constuctive aspects of information systems follwing subsystem integration reliability maintainability performance usability security

24 eneral systems engineering ocesses stem ements eering Syst valida Architectural design System integration Requirements partitioning Sub-system development Software requirements engineering

25 he requirements document A text based document containing the services and functions the system should provide the constraints under which the system must operate overall properties (i.e. constraints on the system s emergent properties) definitions of other systems which the system must integrate with information about the application domain of the system, e.g. how to carry out particular types of computation constraints on the process used to develop the system

26 tandards No single standard exists, but several large organizations have proposed them DOD, IEEE One of the simplest is IEEE/ANSI (IEEE, 1993)

27 EE, 1993 Introduction. Purpose of the requirements document. Scope of the product. Definitions, acronyms and abbreviations. References. Overview of the remainder of the document General description. Product perspective. Product functions. User characteristics. General constraints. Assumptions and dependencies

28 EE, 1993 Specific requirements unctional, non functional, and interface requirements. Also external interfaces, performance requirements, logical database requirements, design constraints, system attributes, and quality characteristics Appendices Index

29 sers of the document System customers Specify the requirements and read them to check that they me their needs. They specify changes to the requirements. Managers Use the requirements document to plan a bid for the system development process. System engineers Use the requirements to understand what system is to be developed System test engineers Use the requirements to develop validation tests for the system System maintanence engineers Use the requirements to help understand the system and the relationship between its parts

30 riting requirements Natural language is often used Some common problems complex conditional statements are confusing terminology often not precise or inconsistent writers assume too much knowledge and leave out essential detail

31 essentials for requirements ocumentation writers Requirements are read more often than they are written Readers come from different backgrounds... do not leave out essential detail It takes a long time. Leave time to write, review, revise.

Requirements Engineering

Requirements Engineering An introduction to requirements engineering Gerald Kotonya and Ian Sommerville G. Kotonya and I. Sommerville 1998 Slide 1 Objectives To introduce the notion of system requirements