Requirements Engineering Csaba Veres

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

Plan 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

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

Why 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 the 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

What are requirements? Requirements define what the system is required to do, and the circumstances under which it must operate. e.g. 1. The system shall maintain records of all library materials 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 using WWW browser. 4. The system shall support at least 20 transactions per second. 5. The system facilities which are available to public users shall be demonstrable in 10 minutes or less.

What 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

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

... 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, repeatable methods for doing the job as well as possible

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

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

FAQ What is requirements engineering? Discovering, documenting, and maintaining requirements Systematic, repeatable techniques to make sure requirements are complete consistent relevant

FAQ How much does RE cost? Depends on the project Around 10% to 15% of total cost

FAQ What 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

FAQ What is a requirements engineering process? Structured set of activities to derive, validate, and maintain requirements document elicitation analysis negotiation validation Ideally should include timelines, tools, responsibilities, etc.

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

FAQ What is a requirements document? THE official statement of the system requirements Describes a number of lower level entities (functional specifications, etc.)

FAQ What 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 department) Make sure ALL stakeholders are consulted, or there will be trouble!

FAQ How do requirements relate to design? Seperate activities? specification vs. solution what vs. how In reality, often there are overlaps system has to fit within existing environment (e.g. ’data has 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

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

Systems 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

Different types of system Information 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

Emergent properties ”non constuctive” aspects of information systems follwing subsystem integration reliability maintainability performance usability security

General systems engineering processes System requirements engineering Architectural design Requirements partitioning Software requirements engineering Sub-system development System integration System validation

The 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

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

IEEE, Introduction 1. Purpose of the requirements document 2. Scope of the product 3. Definitions, acronyms and abbreviations 4. References 5. Overview of the remainder of the document 2. General description 1. Product perspective 2. Product functions 3. User characteristics 4. General constraints 5. Assumptions and dependencies

IEEE, Specific requirements functional, non functional, and interface requirements. Also external interfaces, performance requirements, logical database requirements, design constraints, system attributes, and quality characteristics 4. Appendices 5. Index

Users of the document System customers Specify the requirements and read them to check that they meet 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

Writing 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

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